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The usefulness of computers was 
unclear 

Could anyone figure/out “Software”? 
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KENNEDY SPACE CENTER CONTROL SYSTEM HERITAGE 


Apollo/Saturn 


Shuttle 


KSC developed Command & Control Systems 
Payloads Station 


automated 
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Martin Marietta 
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DDAS- 
Digital Data 
Acquisition 
System 

Separate 
systems for 
spacecraft & 
vehicle. 
Hardwire 
control, 
ground 
versions of 
flight design. 
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SRB Set 


Shuttle firing 
room Command & 
Control System. 
First total ground 
system design. 
Largest computer 
command 
system-mostly 
custom. 

SRB set was 
prototype used at 
MSFC for early 
SRB interface 
testing. 


Introduced networks and 
emerging standards. Generic 
control architecture. 


AFA-Aero Flight Assist Experiment C/O Unit 
*CCTK-Command & Control Tool Kit (Commercial Partner) 
GCS-Generic Checkout System 
CLCS-Checkout & Launch Control System* 

CMU-Control and Monitor Unit 
Core-not acronym* 

IRAD-Internal Research And Development 
PPCU-Partial Payload Checkout Unit 
RTDS-Real Time Data System (DC-X) 

TCMS-Test, Control & Monitor System 
* LPS replacement attempts 


Applied modern 
networks and 
mature standards. 
Generic control 
architecture. 
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Core Overview & 
Harris Command/Control 
Systems Approaches 

September 26, 2007 

. .. . * • 


• Award -1989 

- Engineer, Design, Develop. Manufacture and Sustain 

• Space Shuttle Launch Processing System 
checkout system (Checkout Control and Monitor 
System - CCMS II) 

• Space Station Freedom checkout system 
(Test. Control and Monitor System - TCMS) 

• Contract Realignment -1 994 

- Eliminated CCMS II 

- Minimized TCMS 

• Completed, 1995 






Monitoring and Control Sets 


• Kennedy Space Center 

- Firing Rooms 1-4 (FRx) 

- Hypergolic Maintenance Facility (HMF) 

- Hazardous Processing Facility (HPF) 

- Complex Control Set (CCS) 

- Partial Payload Checkout Unit(PPCU) 

- Cargo Integrated Test Equipment (CITE) 

- Space Station Test, Control and Monitor System 
(TCMS) 

• Johnson Space Center 

- Shuttle Avionics Integration Lab (SAIL) 
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Monitoring and Control Set Configuration 
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To Anafysis 

GSE Right HW 
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Then and Now HAJVZtS 


Aspect 

Then 

Now 

Redundancy/F ariover 

Application 

COTS (HW/SW) 

Design 

Obiect Onented (emergent) 

Service Onented 

Gateways 

Custom HW/SW 

COTS (PLCs) 

Applications 

Custom SW 

COTS 

Data Distribution 

Custom (Common Data Buffer) 

COTS Networks 

Programming Language 

Ada 

Java/C** 








Then- Custom development (HW & SW) 

Now- Standards based HW & SW with minimal development 

= ===== * 
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Harris Approaches for 
Command & Control 
Systems 
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OSICOMET 


Over 25 year* of Guaranteed Mission Assurance for Space Systems TT&C 


COTS product providing Satellite 
Tracking, Telemetry, and 
Commanding 

Over 200 active satellites 
including: 

- GPS 

* Ogital Globe 

- DirecTV 


Some constellations include over 
500K telemetry items 

Database-driven system to 
support any spacecraft, ground 
system, or mission type 

Extensible by the User Non- 
Proprietary Interfaces 

Central Control of Multiple sites 
Reliable and Proven 



OSICOMET Lifecycle Reuse 


bfAimts 



Re-Use of OS/COMET 
through all phases of the 
lifecycle minimizes technical 
risk and nonrecurring cost 


• Databases 

• Procedures 

• Displays 

• Expertise 




Service Oriented Architecture 
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♦ CLCS Description 





CLCS SYSTEM ARCHITECTURE 


WORLD WIDE WEB 


OTHER KSC SYSTEMS 


SIMULATION SYSTEM 

MATH MODELS 

- ORBITER 

- SRB 

- GSE 
-ET 

- PAYLOADS 



SIMULATION CONTROL 
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Business and Support Information Service 

OFFICE PRODUCTS & CAPABILITIES 
MONITORING DATA FROM THE CLCS DATA STREAM 
DATA RETRIEVAL, ANALYSIS & PRESENTATION 
REFERENCE DOCUMENTATION ACCESS 
E-MAIL 

SIMULTION MODEL CONTROL 
OTV CAMERA SELECTION & CONTROL 


MEASUREMENTS 

AND 

COMMANDS 


REAL TIME PROCESSING 
SYSTEM 


DATA ACQUISITION 
DATA DISTRIBUTION 
COMMAND AND CONTROL 
HUMAN COMPUTER INTERFACE 


DATA RECORDING 

-► 



SYSTEM LOAD 
DATA RETRIEVAL 
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SHUTTLE DATA CENTER 

SYSTEM, PLATFORM & TEST BUILD 
DATA RECORDING & RETRIEVAL 
DATA ANALYSIS & PRESENTATION 
MISSION DATA STORAGE & MGMT 
CLDS DISTRIBUTION 
CONFIGURATION MANAGEMENT 

- APPLICATIONS 

- DATA BANK 


CLCS Architecture 
08 / 16/00 




SHUTTLE 

LANDING 


SHUTTLE OPERATIONS OVERVIEW 

Ground Processing Operations 

&L. I 


SRB RETRIEVAL 
SHIP 



RPSF 


HANGAR AF 



ORBITER PROCESSING 
FACILITY 
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6TACKIN& 


Offload 

Buildup 



INTEGRATED 
VEHICLE OPSA/AB 


CT/SKft 

* 1 | I OPERATION) 
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H0RI70NTAL 
PAYLOAD INI. 


PAYLOAD FACILITIES 




PAD OPS 
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CLCS Architecture Overview 



DATA 

DISTRIBUTION 

PROCESSOR 


DATA RECORDING 
PROCESSOR 


RTCN 

(100MB 
T) 




DCN 

(FDDI) 


TEST 

END-ITEM 


HARDWARE 

INTERFACE 

MODULE 


COMMAND & 
CONTROL 
PROCESSOR 


BUSINESS 

NETWORKS 


GSE 

GATEWAY 



SUPPORT WORKSTATION 
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Command & 
Control 
Displays & 
Keyboard 


CLC3 Console layout 
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Operations Control Room 
Console mroupin 
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CLCS Goals 
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Deliver safe, reliable, dependable system that meets 
shuttle checkout needs 

Deliver system which enables increased checkout 
efficiency 

Deliver system with long useful life 

Allow upgrades to keep pace with technology 
Provide expansion room for future needs 
Reduce development & O & M costs 
Use COTS where practical 
Build on previous designs 
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GOTS^C^j^iercial-QfF-the-Shelf: 

Available product requiring no new 
development for use 


dard product in current vendor’s catalog 








Options to COTS 

• Develop it yourself 

• Incur full development cycle costs 

• Sign up for long term sustaining and 
maintenance 

• Use modified COTS 

• Incur some initial development costs 

• Pay continuing sustaining/ maintenance costs 



COTS Downside 

Won ’ L jnairii .all.r.eq uirements ..exactly. 

Requires upgrades at vendor’s convenience 

Upgrades must be synchronized with other COTS 
products 

Will require updates to non-COTS products interfacing 
with COTS 

May drop features in new versions 
Won’t be newest ideas 
May not be fastest or biggest 

Little in depth knowledge of inner workings of product 



COTS Upside 


Development costs shared across large customer base 

Large market base providing product quality feedback to 
vendor 

Trained workforce available 

May include features beyond basic requirements 

Compatibility with other COTS products 



COTS Selection Risk 


Case for 
COTS 


MAINSTREAM MARKET 
MAINSTREAM MARKET NEXT YEAR??? 


FOR NOW 


Risky Business 


FRINGE MARKET 


Market 

Focus 

(Sweet 

Spot) 



Risky Business 


Year 



on 


Use not aligned 
With product 
strength 


COTS Product Features 


Use anticipates 
Future capabilities 
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COTS “No-Brainers” 


Standard multi-vendor supplied with large 
established market: 
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• Oscilloscopes, Voltmeters 

• Memory modules, standard interface boards, 
networks 







COTS “B miners 
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Single vendor supplied products with large established 
market: 

Isolated in system with few interfaces 

Business case driven-savings in development worth risk 
of replacement 

Database software, network analyzers 
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COTS HIGH RISK AR 



Single vendor supplied products with no standard 
interface and small market: 

Critical to system success 


• No second source conversion available 


Take precautions: Escrow agreements, budget 
reserve 
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CLCS EXPERIENCE: 
NETWORKS 
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Asynchronous T ransfer Mode network selected due to 
high capacity and projected commercial support 

• Support did not materialize for real time multicast 
techniques 

• Switched to high speed ethernet with minimal rework 
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Fiber Data Distributed Interface network selected due to 
wide support and failover techniques 

• Support dropped by vendors 

• Switched to high speed ethernet with minimal rework 
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CLCS EXPERIENCE: 
OPERATING SYSTEMS 


• Unix selected due to multivendor support and 
standardization 

• Switched vendor platforms 


• Experienced significant rework even though 
POSIX standards were mostly followed 

• Threads implementation different 

• Library structure and content different 
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CLCS 

BUILDER 

• Used for increased productivity in building 
operator displays 

• Portable across different vendor platforms 


EXPERIENCE: DISPLAY 
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Remained stable through development life 
cycle 

Support has continued to be good 


J 



SUMMARY 


Use of COTS can save development time and provide 
benefits of large use base for testing, user groups and skills 
availability 

Under the wrong conditions, COTS can cause major 
down-the-road expense and loss of support 


CHOOSE WISELY! 





Launch Site Command and Control 

System (LSCCS) 
Proof-of-Concept 
Discussion 


July 2007 


CONSTELLATION 


LSCCS Architecture Overview 
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Launch Site Command & Control System 


> 


Operations 


Control 


Support 


f 

Room 

> Vehicle Gateway . 



( Advisory / Monitor Only Support Facilities 


f Simulation Support 1 
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♦ The architecture and design is based upon the use of mature, industry 
accepted, hardware and software standards and products for 
command and control applications. 

♦ The architecture and design leverages agency investments in a 
common approach for information architecture. 

♦ Specialized Software will be developed only when no suitable 
industry/government product is available 




Timeline of events 



Date 

Event 

Outcome 

June 2005 

Exploration Systems Command and 
Control Tiger Team Formed 

Feasibility study for a Exploration Systems 
Launch Site Command & Control System 

Aug 2005 

Senior Review Team Presentation 

Recommendation for a Launch Site Command 
and Control Architectural Trade Study 

Oct 2005 

KSC Constellation Program office 
requested trade study to evaluate 
candidate launch site C&C 
architectures 

Trade Study Team formed to evaluate C&C 
architectures based on 

1) Legacy C&C Systems 

2) Commercial C&C Systems 

3) Standards Based C&C System 

June 2006 

Ground Ops Project Control Board 
Review 

PCB accepted recommendation to adopt 
Standards Based Architecture for Launch Site 
Command and Control System 

Aug 2006 

KSC Constellation Program Office 
requests a Proof -of-Concept study 
for the Standards Based 
Architecture 

Initial project team formed. 

Specific goals and objectives for trade study 
approved, 

Evaluation H/W and S/W procured. 

June 2007 

Completion of Proof-of-Concept 
Activities 

Proof-of-Concept findings and recommendations 
documented. 

Prototype demonstrations for Launch Site C&C 
System (through August) 

August 2007 

Ground System Control Board 
Authority to Proceed Review 
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CONSTELLATION 


Proof-of-Concept - Background 



♦ The main emphasis is to “buy down” risk for GOP associated with the 
launch site command and control hardware and software development 

♦ The Proof-of-Concept centers on the highest risk areas in the architecture 

• Fault Tolerance 

• Redundancy Management 

• Data Distribution and closed loop performance 

• Telemetry and command processing functionality 

• Scripting language for applications 

♦ The Proof-of-Concept team consisted of: 

• NASA Civil Servants from KSC and ARC 

• KSC on-site contractors 

• Support from JPL and industry field engineers 

♦ Proof-of-Concept was completed in June 2007 

• An prototype of the critical elements of the LSCCS is an outcome from the Proof-of- 
Concept 

• Demonstrations of the LSCCS prototype are being provided throughout July and August 
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CONSTELLATION 


Summary of POC Activities 



Product Group / Component 

Demonstration 

Prototype 

Analysis / Market 
Survey 

RFI 

System Software 





Record and Retrieve 



X 

X 

System Monitoring and Control 

X 

X 

X 

X 

Command & Telemetry Svcs 

X 

X 

X 


Data Distribution Svcs 

X 

X 

X 


Common Services 

X 

X 



Application Framework / Software 

X 

X 

X 


Display Framework 

X 

X 

X 


Application Framework 

X 

X 



Application Software 

X 

X 



Displays 

X 

X 

X 


Information Architecture 

X 

X 

X 


Industrial Controllers 





Hardware 

X 

X 

X 


Servers - Gateways, Apps 

X 

X 

X 


Networks 


X 

X 
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CONSTELLATION 


LSCCS Proof of Concept 
Software Trades & Studies 



♦ System Monitor and Control 

• RFI released to SEWP vendors 

• IBM & HP submitted responses and provided onsite demonstration of their 
tool capabilities 

• HP Openview selected for use in Prototype 

♦ Command and Telemetry Services 

• Performed a Market Survey of 3 commercial toolkits/systems 

• Harris OS/Comet selected for use in the prototype 

- Derived from Naval labs common test environment 

- Has many existing aerospace deployments including Iridium Satellite Control 

- Suitable for C3I architecture and interface requirements compliance 

♦ Data Distribution Service 

• Performed a Market Survey of 2 middleware standards supporting 
publish/subscribe 

• Prismtech Opensplice selected for use in the prototype 

- Has many existing aerospace and DOD deployments 
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CONSTELLATION 


LSCCS Proof of Concept 
Software Trades & Studies 



♦ Domain Specific Languages (DSL) 

• Performed Market Survey and engineering assessment of 22 COTS/GOTS 
languages 

• Down selected to and completed detailed assessment of 6 languages 

• Python selected for use in the prototype 

♦ Information Architecture 

• Working closely with the Level 2 representatives 

• Developed initial prototype concept ontologies using the ARC selected IA 
tool set 

• Providing feedback/modifications to Constellation Foundation Ontology 
based on experience gained populating the ontology with legacy shuttle 
data 

♦ Recording and Retrieval 

• Considers shared, centralized data recording, retrieval, and archiving for all 
types of Constellation vehicle processing data. 

• RFI has been released to industry, and have received 42 responses 

• Evaluated all RFIs, developing requirements for RFP 
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CONSTELLATION 


LSCCS Proof of Concept 
Hardware Trades & Studies 



♦ High Reliability Availability and Serviceability Technology 

• Networks Capability Testing 

- Testing focused on the applicability of ‘best-of-breed’ network technologies and 
ability to meet the performance, fault tolerance, and redundancy management 
requirements of the LSCSS networks 

- No significant surprises were encountered 

• Server Capability Studies 

- Empirical analysis using procured Enterprise class servers provided promising 
results for meeting the reliability, availability, and serviceability (RAS) requirements. 

- Visit to the IBM facility in Austin TX has facilitate in-depth analysis 

- Planned trip to the Sun Microsystems in Sunnyvale later this summer 

♦ Allocation of Control 

• Determination of criteria and design guidelines for allocation of command and 
closed loop control requirements for the GSE has been completed 

- Engineering study has documented approach for balancing the control and monitor 
functions across the control room and the PLC sub-systems with respect to 
performance, safety, and situational awareness 

- Engineering data has been modeled and control scenarios investigated using test 

software 8 
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Hardware Architecture 

Overview 



•Focused on commercial products for supporting Fault 
Tolerance and Redundancy Management 

• Commercial Network Switches 


Room 170B 


Remote I/O 


Co ntrol Net 


• Enterprise Class Servers 

• IBM P5 570 

• IBM P5 560 


User Room #1 
4 CWS's (Linux) 

1 Sun (Solaris 
1 Windows (XP) 

# •••# 


User Room #2 

4 CWS's (Linux) 





PLC Controller 


IBM P5-570 Ethernet/I P 

(Skynet) 

■ IBM P5-560 
(Joshua) 


Command Net 


Utility Net 



Bora Bora 
(SMC Server) 


6 / 19/07 



Core Switch #1 Core Switch #2 


D 


NE-C Router 




Internet 


Simulation 

Server 


POC Hardware Architecture 
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CONSTELLATION 

Simulation 

• GSE/Veh Shuttle Simulation 

Industrial Controllers 
•PLC application 
•GSE math model 

Information Architecture 
•Data Ontology 
•Build Products 

System Software 
•Data Distribution 
•Isolation layers 
•Telemetry processing 

Application 

Framework/Software 

•User displays 

•Application specification 


LCS Software Architecture 

Overview 



LCS Data Flow 


SGOS 

(Vehtcle/GSE Data] 


industrial Control PLC 
[ Embedded Application ] 


T0 102 


Simulation 



PLC Code 


Translator 


Ethcmct/IP 

Driver 

(AIX) 



PLC [GSE Math 


Industrial Controller 


Agency Data Architecture IF Node 



Agency 

Ontology 


KSC 

Specific 

Ontology 


Ll° 


/ Dataetorc 


Simulation Protocol 


(\| _ _ i 

rLL rfOfOCOi 

Adapter 


Adapter 


Harris 

Format 

Conversion 

„ r 






XTCE 


Information Architecture 


Data Distribution 
Service 
(OpenSplice DDS) 


System Software 





Apps 


Application 
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DOS 


Exocut Ion 


MMlI p'' Im 

Adapter 


Engine 





Ported COTS. GOTS 

Java 


Display 

u * IaMM r»| 

Custom Code 

displays 


UvWK/piTH. r*i 

Enviornment 




Application Framework/Software 
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LSCCS Proof-of-Concept 
Selected Prototype Architecture 



Industrial Controllers 



♦ 

♦ 

♦ 


Redundant Power 

Redundant Controllers 
Switchover transparent to 
software 


Gateway Interface Server 


♦ PLC/GSE Data Processing — 
Harris OS Comet 

Telemetry and Command 
Processing - Harris OS Comet 

♦ Data Distribution - OpenSplice 
DDS 

♦ Health & Status Monitor - HP 
Openview 





Demonstration Scenarios 





CONSTELLATION 


♦ Demonstrated scenarios will be based upon Shuttle LH2 launch support 
operations 


Pre-ChillDown 


ChillDown 


Slow Fill (0%-5%) 


Fast Fill (5% - 98%) 


Topping (98%- ) 


Demonstration in Room #2 using Industrial Controller 
Applications 


Demonstration in Room #1 using Application Server 
Applications 


Replenish 


CONSTELLATION 


LSCCS Proof-of-Concept 
Observations and Findings 



♦ Validation of Architectural Approach for LSCCS 

0 The proposed architecture for the LSCCS supports Constellation Program 
operational concepts and element processing requirements. 

0 The proposed LSCCS architecture enables an optimized life cycle cost for 
control system development and sustaining engineering. 

0 The proposed LSCCS architecture is robust and flexible to accommodate 
forthcoming and refined CxP operational support requirements. 

0 Commercially available, high availability, high reliability hardware and software 
are mature technologies and can provide a base for the LSCCS architecture. 


♦ Validation of Development Approach for LSCCS 

0 Development of launch site command and control check-out system using 
commercially available products is achievable within the baseline schedules. 

0 Development team approach using NASA Civil Servants, supporting 

contractors, and acquired products is a viable approach for the delivery of the 
LSCCS to support Constellation operational requirements. 
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CONSTELLATION 


LSCCS Proof-of-Concept 
Early Observations and Findings 




♦ Challenges- Documented Risks 

• Compliance with agency level software development documents remains a 
challenge 

- Expectations of NPR 7150.2 and available evidence of compliance from industry 
not always directly compatible 

- Capability Maturity Model Integration (CMMI) compliance requirements not 
consistently viewed across Level II and Level III 

• Assuming a great deal of automation on board for CEV check-out and 
launch operations 

• Less lines of code needed for ground to flight applications 

• Minimizes tolerances for closed loop control between vehicle and ground 

• Although it significantly reduces the development time, integration of COTS 
hardware and software has been more challenging than expected in some 
areas, 
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